---
title: Accessibility
description: We build Orbit to ensure all users have the most pleasant experience possible, with basic accessibility support automatically in your project by following the Web Content Accessibility Guidelines
redirect_from:
  - /accessibility/
  - /accessibility/accessibility/
---

## Why care about accessibility?

> By designing for someone with a permanent disability,
> someone with a situational limitation can also benefit.
> For example, a device designed for a person who has one arm could be used
> just as effectively by a person with a temporary wrist injury
> or a new parent holding an infant.
>
> Microsoft Inclusive Design

**Consider these use cases when using a phone or our website:**

- Too much bright light---using a mobile device on a beach or in the sun
- Very low display brightness in dark environments
- Not perfectly calibrated glasses or just tired eyes
- Non-quality displays in foreign countries
- Non-stable environment,
  like a bus or subway where you're balancing in a crowd
  and need to find information quick

## Quick overview of accessibility guidelines

The Web Content Accessibility Guidelines (WCAG) are a single shared standard for web content accessibility.
Going through the [WCAG specifications](https://www.w3.org/TR/WCAG21/) might seem, well, overwhelming.
But they're the most complete source for web accessibility.
And navigating them can be easier then you might think.
Rather than jumping into the complete specifications,
go with a [quick reference guide](https://www.w3.org/WAI/WCAG21/quickref/).

The guide shows you all the rules with short descriptions
and then techniques and failures for each rule.
To pass each rule, implement one of the sufficient techniques and avoid the failure criteria.
You can also visit each criterion, which has its own page describing it in detail,
sometimes with implementation examples.

Learn more:

- [Web Content Accessibility Guidelines (WCAG) Overview](https://www.w3.org/WAI/standards-guidelines/wcag/)
- The [new guidelines in WCAG 2.1 explained](https://blog.prototypr.io/the-new-guidelines-in-wcag-2-1-explained-c26e62b196f2)

## What we offer and what you can do

As Orbit, we try our best to have accessible components from the get go
and abstract as much we can for developers.
For example, we have a few components that help you to make your websites more accessible.

<FancyLink title="SkipLink" href="/components/accessibility/skiplink/" icon="lightbulb" />

<FancyLink
  title="SkipNavigation"
  href="/components/accessibility/skipnavigation/"
  icon="lightbulb"
/>

However, we can't do everything as making products accessible is a team effort.
Below, you can find a list of current components where we need your help
to ensure proper accessibility support.

| React Component   | What Orbit offers                         | What you need to do                                                                                             |
| ----------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Badge             | Screen reader support                     | Fill `ariaLabel` if there is a need for more information than you can fit in `content`                          |
| Button            | Screen reader/keyboard navigation support | Read about [Button's multiple accessibility properties](/components/action/button/react/#accessibility)         |
| ButtonLink        | Screen reader/keyboard navigation support | Read about [ButtonLink's multiple accessibility properties](/components/action/buttonlink/react/#accessibility) |
| Card              | Screen reader/keyboard navigation support | Use the `dataA11ySection` property when needed                                                                  |
| Heading           | Screen reader support                     | Use the `dataA11ySection` property when needed                                                                  |
| NotificationBadge | Screen reader support                     | Fill `ariaLabel` if there is a need for more information than you can fit in `content`                          |

## Screen readers (assistive technologies)

Screen readers are the core assistive technology for visually impaired or blind users.
Navigating an improperly designed website with such disabilities is a very different experience,
and until you try yourself you might never understand how complicated it can be
to do things people take for granted.
If you want to understand keyboard navigation and screen readers little more,
read [an article on the experience](https://www.smashingmagazine.com/2018/12/voiceover-screen-reader-web-apps/)
and try it out yourself.
Understanding the user context is the first step to being able to develop and design for their needs.

Luckily, all major operating systems already have a screen reader included,
so you can just open it, follow the basic tutorial, and go on the web.
Mentioning the tutorial here isn't a coincidence.
Screen readers are powerful tools with a lot of interesting features.
They allow users to jump to headings, find the closest buttons, and lot more.
To get better idea of what screen readers can do for a user,
take a look at those basic command cheat sheets for [voiceOver on Mac](https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts)
or for [Windows](https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts).

Learn more:

- [A video on how screen readers work and sound](https://www.youtube.com/watch?v=7Rs3YpsnfoI)
- [A video from a screen reader user on why and how she uses it](https://www.youtube.com/watch?v=eOdjjRA9vBw)
- [Funkify, a Chrome extension that simulates browsing the web with different abilities](https://www.funkify.org/)

### `dataA11ySection` property

We introduced this property across our design system to enhance our accessibility.
The Navigation component serves as quick navigation for actions that can be hidden
or hard to reach from keyboard navigation.
The `dataA11ySection` property then servers as a pointer for this navigation.

## Color

With accessibility regarding color, there are two main parts to keep in mind.

### Ensure proper color contrast

- **Minimum requirement: Level A according to WCAG**
  The contrast ratio between the background and foreground should be at least 3:1
  as this ratio is recommended for users with any vision.
- **Recommended requirement: Level AA according to WCAG**
  We should have a contrast ratio of at least 4.5:1 between the background and foreground.
  There is an exception for larger text over 24px (or 18px bold):
  the contrast ratio in such cases should be at least 3:1.
  This color contrast ratio should be used for
  any color used to show important information (icon and text).

Orbit provides an [accessible palette of colors](/foundation/color/).

> Disclaimer: we know about slight contrast issues in the product color
> and we're working toward fixing that.

Tip: Avoid using pure black text on a pure white background as it's difficult to read for dyslexic users.
The combination of these colors causes the words to blur together.

### Convey information with more than just color

A message conveyed with color alone is completely lost for some users.
For example, don't indicate an error only with red,
as the inability to distinguish red and green is the most common type of color blindness.

It's important to convey information in multiple ways
and make sure the message is clear even with CSS disabled.
You can use labels or icons to convey errors and important states.

## Typography

Clear typography helps ensure the content is readable and everyone can follow the flow of the text.
This means making sure the text is big enough to read
and the spacing around the text makes it easy to distinguish what should be read.

### Font size

Having a clear base size for the text enables you to base other sizing and spacing relative to that.
See the [Typography section](/foundation/typography/) for how it works in Orbit.

Keep in mind that many users use zoom and other technology
to resize the text to fit their needs.
Make sure your content works with no overlapping or need to scroll horizontally,
even with the text at 200% of the base size.

### Line spacing

Proper spacing of lines helps readers track their progress through lines
and recognize when they've reached the end of a paragraph.
This means it's important to think about spacing both within and between paragraphs.

Within a paragraph, you want to aim for a line height that's about 1.5 times the font size.

Spacing between paragraphs and other elements should be enough
to distinguish different elements while keeping related elements connected.
See the [section on spacing](/foundation/spacing/) for more on the Orbit system.

### Line length

Long lines of text can be hard to follow and make readers lose their place in the text.
With shorter lines, it's easier to flow from one line to the next.

Make sure your lines don't exceed 80 characters
(or 40 for Chinese, Japanese, or Korean characters as those are about twice as wide).
Lines can be shorter as well, down to 50 (or 25) characters.

### Justification

Justifying text to both the right and left can create uneven spacing
("[rivers of white](<https://en.wikipedia.org/wiki/River_(typography)>)"),
which makes it hard to follow the flow of the text.
That's why Orbit [Text](/components/text/) components don't offer this as an alignment option.
Base the text alignment off the directionality of the language.

## Bi-directionality (RTL)

Users of right-to-left (RTL) languages expect their content to start on the right side.
This expectation sets the basis for all their interactions.
If only the text starts on the right,
it makes it harder for users to understand what to do to accomplish their goals.

Luckily, Orbit components are designed to work in both directions.
This lets you mirror your layouts so the important aspects are clear to users of any language.
You can see [how to implement RTL language support with Orbit](/development/utilities/rtl-languages/).

As a part of this process, important visual clues (like a forward arrow pointing to the right on a Tile)
are mirrored in RTL presentation (the arrow points to the left by default).

When building mirrored layouts, it's important to recognize that not everything should be mirrored.
For example, numbers stay the same.
Also, many icons, such as the magnifying glass of search,
are designed to work no matter the direction of the text,
so the icons default to not reversing based on RTL settings (though you can manually override this).

Focusing on making sure your designs make sense from each direction
helps ensure they're usable by everyone.

## Scale

When designing across devices, window sizes, and orientations,
it can be difficult to maintain a consistent look that's usable at various scales.
It's important to ensure that people can use your designs however they access them.

### Media queries

With Orbit, it's important to always design for mobile first
and make sure everything works at that scale.
Once that's ready, you can scale your designs up to reach various audiences.

To get your designs to work,
take advantage of Orbit [media queries](/development/utilities/media-queries/).
This can help make sure you're using the space available to you
and not blocking out features at various scales.

### Target sizes

When working in smaller sizes, such as small mobiles,
designers often want to increase the real estate they have available.
So they group targets (buttons and other interactions) together
and make them small to make more room elsewhere.

The problem, as anyone who's tried to hit the bullseye on a dartboard 🎯 knows,
is that smaller targets are harder to hit.
And when small targets are closer together,
it makes it more likely that users hit the wrong target accidentally,
increasing their frustration with your design.

So especially in mobile designs,
you want to make sure your targets are designed for human fingers.
This means aiming for sizes that are 7 to 10 mm wide.
(Note that this involves the target size,
which can include padding and isn't limited to only visible icons.)

This translates to different values depending on the device,
but can be generalized as at least 44 by 44 CSS pixels.
An example is an Orbit circled [Button](/components/action/button/) at normal size.

Then to make sure each target can be used separately,
make sure to include enough spacing between each target.
This is usually set as at least 8 CSS pixels,
which you can see in the Orbit [design tokens for button margins](/foundation/design-tokens/#spacing).

It's also important to keep in mind that the edges of screens aren't so easily accessible
or may be used for swipe gestures,
so you want to add extra spacing for any targets near the edge.

When you size and space your targets properly,
you make your designs usable for people whose hands shake, older people,
people with disabilities, people with large fingers, and more.

And the great thing is that when you plan your designs like this on a mobile scale,
scaling them up helps people with targeting on desktops.
This ensures your design are usable in all situations.

## Things to keep in mind while developing

- Make sure your HTML uses proper semantics and is well-structured
  so the application is understandable and usable with CSS disabled
  (or when read by screen readers).
- Any text in ALL CAPS should be typed in its proper casing
  and capitalization should be achieved using CSS.
- All non-text content (photo, icons, illustrations, and so on) need to have alternative text.
- All major functionality should be accessible by keyboard.

## Hooked on accessibility?

Here are some interesting sources you can explore!

- [Inclusive Design Principles](https://inclusivedesignprinciples.org/)
- [Microsoft Inclusive Manual](https://www.microsoft.com/en-us/design/inclusive)
- [7 thing every designer needs to know about accessibility](https://medium.com/salesforce-ux/7-things-every-designer-needs-to-know-about-accessibility-64f105f0881b)
